The present invention relates to a system, method, and network elements for providing a service such as a Supplementary Service, preferably an Advice of Charge, AoC, Supplementary Service. The service may preferably be provided with or for another service such as a communication service which may e.g. be a voice communication service, a data communication service, a multimedia communication service, etc. The supplementary service and the communication service are provided in a communication network with a suitable protocol, preferably Session Initiation Protocol, SIP, and preferable in a SIP network such as the IP Multimedia Subsystem (IMS).
Document Draft ETSI TS<3030> V<0.0.3> (2004-11) describes a proposal for providing an Advice of Charge, AoC, service as a supplementary service in a mobile communication network using Session Initiation Protocol (SIP). For circuit switched networks the service has been standardised by International Telecommunication Union (ITU) early 1990s (in standards 1.256.2a-c (3/93) and Q.86 (10/95), GSM 02.86, 03.86, 04.86, and 3GPP 22.086, 23.086, and 24.086). The AoC service provides a charging information at communication set-up time (AOC-S), or communication end. The AoC at communication set-up supplementary service provides the served user with information about the charging rates at the time of communication establishment or during the communication in the case of charging rates changes. The charge information given relates to the charges incurred on the network to which the served user is attached. The supplementary service may apply for both originating and terminating calls, e.g., roaming leg.
An advantageous implementation of the AoC service should provide the originator of the session to provide her/his “go ahead” with the session setup once she/he has been informed of the potential charges and has agreed with them. Such a function is difficult to implement. When trying to implement this function with SIP SUBSCRIBE/NOTIFY methods, INFO or MESSAGE for notifications, or even notifications embedded in a provisional response, difficulties arise. An S-CSCF would, in some cases, have to “hold” the processing of an INVITE request until some event happens such as perhaps the reception of a NOTIFY from an Application Server, AS, indicating the charge. This concept is difficult to implement since it requires correlating messages belonging to different dialogs. Furthermore, it requires changes to the S-CSCF since part of the AoC logic is to be implemented in the S-CSCF, and part in the AoC Application Server. This approach also contradicts the idea of implementing the logic of the service in dedicated application servers, and keeping the S-CSCF with the original routing and triggering functions.
Further, an alternative concept based on an AoC AS acting as a Back-to-Back User Agent, B2BUA, would undesirably require implementing the B2BUA with additional logic to correlate two dialogs on two different sides (like sequence numbers, From/To headers, etc.). Additionally it would prevent the use of any kind of end-to-end security (S/MIME), and thus prevent the use of extensions that are otherwise required to be understood by user agents.